<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<!-- Casting SPELs in Lisp - Emacs Lisp Edition, a Comic Book
     Written by Conrad Barski, M.D., http://lisperati.com
     Edited by James A. Webb, http://uberkode.com -->

<head>

  <title>Casting SPELs in Lisp (17)</title>
  <meta http-equiv="content-type" content="text/html;charset=utf-8" />
  <meta http-equiv="Content-Style-Type" content="text/css" />
  <meta name="author" content="James A. Webb" />
  <meta name="date" content="2007-09-16T00:00:00+00:00" />
  <meta name="keywords" content="Emacs, Lisp" />

</head>

<body>

<center>

<table cellspacing="10" width="500">
  <tr>
    <td>
      This "back-quoting" technique is a great feature in Lisp- it
      lets us write code that looks just like the data it
      creates. This happens frequently with code written in a
      functional style: By building functions that <i>look</i> like 
      the data they create, we can make our code easier to understand 
      and also build for longevity: As long as the data doesn't 
      change, the functions will probably not need to be refactored 
      or otherwise changed, since they mirror the data so closely. 
      Imagine how you'd write a function like this in VisualBasic or
      C: You would probably chop the path into pieces, then append
      the text snippets and the pieces together again - a more
      haphazard process that "looks" totally different from the data
      that is created and probably less likely to have longevity.
    </td>
  </tr>
  <tr>
    <td>
      Now we can describe a path, but a location in our game may 
      have more than one path, so let's create a function called 
      <tt>describe-path<b>s</b></tt>:
    </td>
  </tr>
  <tr>
    <td>
<pre style="font-weight: bolder; color: darkblue">
  (defun describe-paths (location map)
    (apply #'append (mapcar #'describe-path (cddr (assoc location map)))))
</pre>
    </td>
  </tr>
  <tr>
    <td>
      This function uses another common <i>Functional Programming</i> 
      technique: The use of <i>Higher Order Functions</i> - This 
      means that the <tt>apply</tt> and <tt>mapcar</tt> functions 
      are taking other functions as parameters so that they can call 
      them themselves. To pass a function, you need to put 
      <tt>#'</tt> in front of the function name. The <tt>cddr</tt> 
      command chops the first two items from the front of the list 
      (so only the path data remains). The <tt>mapcar</tt> simply 
      applies another function to every object in the list, basically 
      causing all paths to be changed into pretty descriptions by the 
      <tt>describe-path</tt> function. The <tt>apply #'append</tt> 
      just cleans out some parentheses and isn't so important. Let's 
      try this new function:
    </td>
  </tr>
  <tr>
    <td>
<pre style="font-weight: bolder; color: darkblue">
  (describe-paths 'living-room map)
</pre>
    </td>
  </tr>
  <tr>
    <td>
<pre style="font-weight: bolder; color: darkgreen">
  ==> (there is a door going west from here - there is a stairway 
       going upstairs from here -)
</pre>
    </td>
  </tr>
  <tr>
    <td>
      Beautiful!
    </td>
  </tr>
  <tr>
    <td align="center">
      &lt;&lt; <a href="casting-spels-emacs-1.html">begin</a>
      &lt; <a href="casting-spels-emacs-16.html">previous</a> - 
      <a href="casting-spels-emacs-18.html">next</a> &gt;
      <a href="casting-spels-emacs-35.html" >end</a> &gt;&gt;
    </td>
  </tr>
</table>

</center>

</body>

</html>